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This  software  product  and  documentation  and  all  future  updates  to  it 
are  provided  by  the  United  States  Government  and  the  Defense 
Communications  Agency  (DCA)  for  the  intended  purpose  of  conducting 
conformance  tests  for  the  DoD  suite  of  higher  level  protocols.  DCA  has 
performed  a  review  and  analysis  of  the  product  along  with  tests  aimed 
at  insuring  the  quality  of  the  product,  but  does  not  warranty  or  make 
any  claim  as  to  the  quality  of  this  product.  The  product  is  provided 
"as  is"  without  warranty  of  any  kind,  either  expressed  or  implied.  The 
user  and  any  potential  third  parties  accept  the  entire  risk  for  the 
use,  selection,  quality,  results,  and  performance  of  the  product  and 
updates.  Should  the  product  or  updates  prove  to  be  defective, 
inadequate  to  perform  the  required  tasks,  or  misrepresented,  the 
resultant  damage  and  any  liability  or  expenses  incurred  as  a  result 
thereof  must  be  borne  by  the  user  and/or  any  third  parties  involved, 
but  not  by  the  United  States  Government,  including  the  Department  of 
Commerce  and/or  The  Defense  Communications  Agency  and/or  any  of  their 
employees  or  contractors. 


This  software  package  and  documentation  is  subject  to  a  copyright. 

This  software  package  and  documentation  is  released  to  the  Public 
Doma i n . 

Permission  to  copy  without  fee  all  or  part  of  this  material  is  granted 
provided  that  the  copies  are  not  made  or  distributed  for  direct 
commercial  advantage. 


Comments 


Comments  or  questions  about  this  software  product  and  documentation  can 
be  addressed  in  writing  to:  DCA  Code  R640 

1360  Wiehle  Ave 
Reston,  VA  22090-5500 

ATTN:  Protocol  Test  System  Administrator 
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TRANSMISSION  CONTROL  PROTOCOL  (TCP) 
MIL-STD-1778 
TRACEABILITY  MATRIX 


This  Traceability  Matrix  provides  information  on  the  derivation, 
organization,  and  function  of  tests  specified  for  TCP  within  the 
Protocol  Test  System. 

The  document  is  divided  into  four  sections: 


TCP  TRACEABILITY  INDEX; 

TCP  TEST  INDEX; 

TCP  TEST  SCENARIOS  INDEX; 

TCP  SCENARIOS  AND  TEST  DESCRIPTIONS. 


TCP  TRACEABILITY  INDEX:  TCP  TEST  NUMBERS  VERSUS 
TCP  MIL-STD-1778  .  .  . 

The  table  indicates  the  cross-reference  between  the  Test 
Scenarios  and  the  applicable  sections  in  MIL-STD-1778 
regarding  each  required  function,  operation,  option,  mode, 
response,  or  state. 


TCP  TEST  INDEX:  TCP  TEST  NUMBERS  VERSUS 
TCP  COMMANDS/PRIMITIVES/OPTIONS/MODES  .  .  . 

The  table  shows  the  TCP  Test  Numbers  that  may  be  regarded  as  the 
"principle  tests"  of  each  TCP  Command  or  Primitive  and  Option  or 
Mode . 


TCP  TEST  SCENARIOS  INDEX:  TCP  TEST  SCENARIO  FILES  VERSUS  TCP 
TEST  NUMBERS  .  .  . 

The  table  shows,  for  each  TCP  Test  Number,  the  UNIX  file  name  of 
the  TCP/IP  Test  Scenario  File  in  which  that  number  appears. 
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TCP  SCENARIOS  AND  TEST  DESCRIPTIONS  .  .  . 

This  section  provides  a  brief  narrative  of  the  scope  and 
objectives  of  each  TCP  Test  Scenario  File  and  an  operational 
description  of  each  TCP  Test  Number. 


SECTION  1  -  TCP  TRACEABILITY  INDEX 
TCP  Test  Numbers  Versus  TCP  MIL-STD-1778 

The  table  indicates  the  cross-reference  between  the  TCP  tests  and 
the  applicable  sections  of  MIL-STD-1778. 


Reference 

Test  Number 

TCP  Service 

Request  Primitives 

6.4.1 

Unspecified  Passive  Open 

1,  39,  57 

6.4.2 

Fully  Specified  Passive  Open 

9,  10,  40 

6.4.3 

Active  Open 

2,  38,  55 

6.4.4 

Active  Open  with  Data 

11,  12 

6.4.5 

Send 

3,  14-16,  56 

6.4.6 

A1  locate 

51 

6.4.7 

Close 

6,  7,  14-16 

6.4.8 

Abort 

17-20 

6.4.9 

Status 

24 

TCP  Service 

Response  Primitives 

6.4.10.1 

Open  ID 

1,  2,  9-11 

6.4.10.2 

42, 

Open  Failure 

35,  371,  41, 

49,  63 

6.4.10.3 

Open  Success 

1,  2,  66 

6.4.  L0.4 

Deliver 

3,  6 

6.4.10.5 

Closing 

6,  7 

6.4.10.6 

Termina  te 

6,  7,  17-21, 
44-46,  55-58 

6.4.10.7 

6.4. 10.8 


Status  Response 
Error 


24 

4,  5,  31,  38, 
40,  73 
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Reference 

Test  Number 

TCP  Mechanisms 

Tested 

9.2.3 

Flow  Control  Window 

59,  61 

9.2.4 

Duplicate/Order  Detection 

25-27,  29, 

9.2.5 

ACKs  and  Retransmission 

27,  52-54 

9.2.6 

Checksum 

28 

9.2.7 

Push 

63,  64 

9.2.8 

Urgent 

60-62 

9.2.9 

ULP  Timeout/Action 

55-58 

9.2.10 

Security 

38-50 

9.2.11 

Precedence  Level 

21-23 

9.2.12 

Multiplexing 

30-34,  36 

9.2.13 

Connection  Opening 

35,  37 

9.2.14 

Connection  Closing 

14-17 

9.2.15 

Resets 

35,  50,  65- 

9.3.1 

Source  Port  Address  Range 

13 

9.3.2 

Destination  Port  Address  Range 

13 

TCP  Options  Tested 

9.3.11.1.3 

Maximum  Segment  Size 

52 

4 


The  table  shows 
"principle  tests 
option. 


Test  Number 

1 

2 

3 

4 

5 

6 

7 

8 


9 

10 

11 

12 

13 


14 

15 


16 


17 

18 

19 

20 
21 
22 

23 

24 


25 

26 

27 

28 
29 


SECTION  2  -  TCP  TEST  INDEX 

the  TCP  Test  Numbers  that  may  be  regarded  as  the 
"  for  each  TCP  service  request,  response,  and 


Purpose 

Unspecified  Passive  Open  Request 
Active  Open  Request 
Basic  Data  Transfer 

Remote  Driver  Interpretation  of  Command  LCN 
Determine  IUT  Standard  Send  Buffer 
Closing  Handshake  -  IUT  initiates  close 
Closing  Handshake  -  IUT  peer  initiates  close 
Ability  to  Reconnect  Remote  Driver  Command 
Channel 

Fully  Specified  Passive  Open  Request 
Illegal  Fully  Specified  Passive  Open  Request 
Active  Open  with  Data 
Active  Open  with  Data 
Port  Number  Range 

Graceful  Closing  -  Completion  of  data  transfer 
after  ULP  close 

Graceful  Closing  -  Data  transfer  after  receipt 
of  peer's  FIN 

Graceful  Closing  -  Peer  data  transfer  after  IUT 
initiates  close 
ULP  Abort 
Peer  Abort 

ULP  Abort  -  Data  queued  for  sending 

Peer  Abort  -  Data  queued  for  sending 

Precedence  -  Mismatched 

Precedence  -  Matched 

Precedence  Negotiation 

Status 

Out-of-Order  Data 
Overlapping  Data 
Lost  Data 

TCP  Bad  Checksum  Detection 
Sequence  Number  Wraparound 
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Test  Number 


Purpose 


Multiplexing  -  Two  connections  with  unique 
4-tuple  IUT  opens  passively 
Multiplexing  -  Common  destination  port  in 
4-tuple  common  IUT  port 
Multiplexing  -  Common  destination  port  in 
4-tuple  common  REF  port 
Multiplexing  -  Two  connections  with  unique 
4-tuple  IUT  opens  actively 
Multiplexing  -  Three  connections  with  common 
IUT  port  in  4-tuple 

Duplicate  Connection  Attempt  -  IUT  Passive 
Multiplexing  -  Same  sequence  numbers  on  two 
connections 

Duplicate  Connection  Attempt  -  IUT  Active 

Setting  Security  in  Active  Open 
Setting  Security  in  Passive  Open 
Setting  Security  in  Fully  Specified  Passive 
Open 

Secure  IUT  rejecting  connection  to  unsecured 


peer 

Secure  IUT  rejecting  connection  from  unsecured 
peer 

Security  option  placement  in  sending  data 
Response  to  data  with  mismatched  security  class 
Response  to  data  with  mismatched  security 
protection  authority 
Response  to  data  with  extra  protection 
author i ty 

Use  of  security  option  for  unclassified 
connections 

Recognition  of  UNCLASS  and  GENSER  as  unsecured 
Unsecured  IUT  response  to  connection  attempt  by 
secured  host 

Unsecured  IUT  response  to  data  marked  with 
classified  security 

Alloc 

Maximum  segment  size  option 

Retransmission  after  acknowledgment  of  data 
Retransmission  after  acknowledgment  of  SYN  and 
FIN 

ULP  timeout  service  in  Active  Open 

ULP  timeout  service  in  Send 

ULP  timeout  service  in  Passive  Open 


Test  Number 


58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 
7  ] 
72 


TCP  in  window  mechanism 
Urgent  service 

Urgent  service  when  peer  has  zero  window 
Urgent  data  delivery 

Push  service  -  Service  not  requested 
Push  service  -  Service  requested 


Reset  -  as  response  to  connection  refusal 

Reset  -  partial  reset  prior  to  connection 
establ ishment 

Reset  -  response  to  reset  received  while 
sending  data 

Reset  segment  format  on  receipt  of  Active  Open 
with  no  listening  port 

Reset  segment  format  on  receipt  of  Active  Open 
with  data  with  no  listening  port 

Reset  segment  format  on  receipt  of  invalid 
segment  with  ACK  set 

Reset  segment  format  on  receipt  of  invalid 
segment  with  SYN  and  ACK  set 

Reset  -  no  reset  sent  on  receipt  of  segment 
with  bad  acknowledgment  number 


Determine  number  of  connections  resources  will 
a  1  low 


73 


SECTION  3  -  TCP  TEST  SCENARIOS  INDEX 


The  table  shows,  for  each  TCP  Test  Number,  the  UNIX  file  name  of 
the  TCP  Scenario  File  in  which  it  appears. 


Test  Number 


Scenario  Name 


1 

2 

3 

4 

5 

6 

7 

8 


BASIC 

BASIC 

BASIC 

BASIC 

BASIC 

BASIC 

BASIC 

BASIC 


9 

10 

11 

12 

13 

22 

23 

24 


OPEN 

OPEN 

OPEN 

OPEN 

OPEN 

OPEN 

OPEN 

OPEN 


14 

15 

16 

17 

18 

19 

20 
21 


CLOSE 

CLOSE 

CLOSE 

CLOSE 

CLOSE 

CLOSE 

CLOSE 

CLOSE 


25 

26 

27 

28 
29 


RELIABILITY 
RELIABILITY 
PFI.  TAP  1 1  TTY 
RELIABILITY 
RELIABILITY 


30 

31 

31 

32 

33 

34 

35 

36 

37 


MULTIPLEX 

MULTIPLEX 

MULTIPLEX 

MULTIPLEX 

MULTIPLEX 

MULTIPLEX 

MULTIPLEX 

MULTIPLEX 

MULTIPLEX 


Test  Number 


Scenario  Name 


SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

SECURITY 

ALLOC 

POLICY 

POLICY 

POLICY 

POLICY 

POLICY 

POLICY 

POLICY 

OUT_OF_BAND 

OUT_OF_BAND 

OUT_OF__BAND 

OUT_OF_BAND 

OUT_OF_BAND 

OUT_OF_BAND 

RESET 

RESET 

RESET 

RESET 

RESET 

RESET 

RESET 

RESET 


SECTION  4  -  TCP  SCENARIOS  AND  TEST  DESCRIPTIONS 


This  section  provides  a  brief  narrative  of  the  scope  and 
objectives  of  each  tightly  coupled  TCP  Test  Scenario  file  and 
describes  individual  tests  in  each  scenario. 


Scenario  BASIC 

Scenario  BASIC  is  the  first  TCP  test  of  a  test  session.  This 
scenario  tests  the  most  basic  TCP  functions  of  the  TCP 
Implementation  Under  Test  (IUT)  and  the  compliance  of  the  IUT 
Remote  Driver  (RD)  to  the  TCP  Remote  Driver  Specification.  If 
the  IUT  and  the  RD  do  not  receive  good  results  on  the  first  run 
of  this  scenario,  further  testing  should  be  abandoned  until  the 
problems  exhibited  are  corrected. 

BASIC  tests  the  TCP  implementation  for  its  ability  to  perform  the 
most  basic  TCP  functions:  Active  Open,  Passive  Open,  transfer  of 
data,  and  closing.  The  scenario  determines  that  the  Remote 
Driver  interprets  Central  Driver  (CD)  commands  correctly, 
acknowledges  the  receipt  of  a  command  from  the  CD,  and  correctly 
formats  IUT  responses  that  it  sends  to  the  CD. 

TEST  1:  UNSPECIFIED  PASSIVE  OPEN 


Does  the  IUT  implement  a  Passive  Open  that  accepts  an  Active  Open 
request? 

-  Action:  PD  per  f  :  r~s  2  ~:ie:  :  f  :ed  Passive  Open. 

La  cor  a*.  •  '  :  ever  DSD 1  does  an  Active 

Open  *  :  •  . 

-  Verification:  •  -  .  •  •  •  rv  3  on  meet  ion  is  made  by 

f  i.nd :  r.g  a-  OPEN  SUCCESS  response  from  the  LSD. 
Ensure  *  -  a*  *  no  :  acknowledges  all  commands 
received  from  t  re  IT.  Determine  that  all  RD 
responses  are  "rrc-r*.  v  formatted. 


10 


-  Success:  The  connection  is  made.  The  RD  correctly 

interprets  CD  commands,  acknowledges  CD 
commands,  and  formats  IUT  responses. 

-  Failure:  Connection  is  not  made  or  the  RD  does  not 

correctly  interpret  CD  commands,  acknowledge  CD 
commands,  or  format  IUT  responses. 


TEST  2:  ACTIVE  OPEN 


Can  the  IUT  implement  an  Active  Open? 

-  Action:  LSD  performs  a  Passive  Open.  The  RD  does  an 

Active  Open  to  the  listening  port. 

-  Verification:  Determine  that  a  connection  is  made  by 

finding  an  OPEN  SUCCESS  response  from  the  RD. 
Ensure  that  the  RD  acknowledges  all  commands 
received  from  the  CD.  Determine  that  all  RD 
responses  are  correctly  formatted. 

-  Success:  The  connection  is  made.  The  RD  correctly 

interprets  CD  commands,  acknowledges  CD 
commands,  and  formats  IUT  responses. 

-  Failure:  Connection  is  not  made  or  the  RD  does  not 

correctly  interpret  CD  commands,  acknowledge 
CD  commands,  or  format  IUT  responses. 


TEST  3:  BASIC  DATA  TRANSFER 


Does  the  IUT  send  and  deliver  data  correctly? 

-  Action:  The  LSD  sends  data  to  the  RD.  The  RD  sends 

data  to  the  LSD. 

-  Verification:  Ensure  that  all  the  data  that  the  IUT  is 

directed  to  send  to  the  LSD  is  received  by  the 
Laboratory  Reference  Implementation  (REF). 
Check  that  all  the  data  sent  by  the  LSD  is 
delivered  to  the  RD  by  the  IUT.  Ensure  that 
the  RD  acknowledges  all  commands  received  from 
the  CD.  Determine  that  all  RD  responses  are 
correctly  formatted. 


V", 


V 


R 

R 


-  Success:  The  IUT  sends  all  the  data  it  is  requested  to 

send  and  delivers  all  the  data  it  receives. 
The  RD  correctly  interprets  CD  commands, 
acknowledges  CD  commands,  and  formats  IUT 
responses . 

-  Failure:  The  IUT  does  not  send  all  the  data  it  is 

requested  to  send  or  does  not  deliver  all  the 
data  it  receives.  Also,  the  RD  does  not 
correctly  interpret  CD  commands,  acknowledge 
CD  commands,  or  format  IUT  responses. 


TEST  4:  SIGNIFICANCE  OF  COMMAND  LCN  TO  REMOTE  DRIVER  AND  IUT 


Do  the  IUT  and  the  IUT  Remote  Driver  correctly  interpret  the  local 
connection  name  (lcn)  specified  in  the  commands  the  RD  receives 
from  the  Central  Driver? 

-  Action:  The  CD  sends  a  Send  command  to  the  RD  that 

contains  an  lcn  for  a  connection  that  is  not 
established.  The  RD  requests  the  IUT  to  send 
data  to  the  LSD  over  this  connection. 

-  Verification:  Ensure  that  the  RD  reports  in  correct 

format  that  the  IUT  responds  to  the  incorrect 
lcn  with  TCP  ERROR:  CONNECTION  DOES  NOT  EXIST. 

-  Success:  The  IUT  recognizes  an  invalid  lcn.  The  RD 

correctly  interprets  CD  commands,  acknowledges 
CD  commands,  and  formats  IUT  responses. 

-  Failure:  The  IUT  does  not  recognize  an  invalid  lcn. 

Also,  the  RD  does  not  correctly  interpret  CD 
commands,  acknowledge  CD  commands,  or  format 
IUT  responses. 


TEST  5:  DETERMINE  IUT  STANDARD  SEND  BUFFER  FOR  TESTING  PURPOSES 


Determine  the  standard  size  buffer  that  the  IUT  requires  to 
guarantee  that  the  IUT  will  output  at  least  two  segments  without 
delay . 

-  Action:  The  RD  issues  a  series  of  Send  commands;  each 
command  requests  a  larger  increment  of  data  to 
be  sent.  After  each  Send  command,  the  LSD 
waits  for  the  data  to  be  delivered.  Once  the 
data  is  delivered,  check  the  TCP  segments 
collected  by  the  REF  to  determine  if  more  than 
one  segment  was  required  to  send  the  data. 
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When  more  than  one  segment  is  used  to  send  the 
data  or  the  response  TCP  ERROR:  INSUFFICIENT 
RESOURCES  is  returned  by  the  IUT,  the  test  is 
ended . 


-  Verification:  When  a  Send  command  data  length  requires 

the  IUT  to  send  the  data  in  more  than  one 
segment,  that  data  length  is  noted.  If  the 
response  TCP  ERROR:  INSUFFICIENT  RESOURCES  has 
been  reported,  the  data  length  of  the  Send 
command  immediately  preceding  the  command  that 
caused  that  response  is  noted. 

-  Observation:  The  IUT  standard  send  buffer  is  noted  for 

the  test  operator. 


TEST  6:  CLOSING  HANDSHAKE  WHEN  IUT  INITIATES  CLOSE 


Does  the  IUT  correctly  perform  the  closing  handshake  when  it 
initiates  closing? 

-  Action:  The  RD  performs  a  close.  When  the  LSD  receives 

the  indication  of  peer  closing  from  the  REF, 
the  LSD  performs  a  close. 

-  Verification:  Ensure  that  the  RD  reports  TERMINATE: 

CONNECT ION  CLOSED  or  TERMINATE:  ULP  CLOSE  when 
the  IUT  indicates  the  connection  closed.  Check 
the  TCP  segments  collected  by  the  REF  to 
determine  that  the  IUT  acknowledged  the  FIN 
from  the  REF  before  it  terminated. 

-  Success:  The  IUT  acknowledges  the  FIN  of  the  REF.  The 

IUT  reports  its  connection  closed.  The  RD 
correctly  interprets  Central  Driver  commands, 
acknowledges  CD  commands,  and  formats  IUT 
responses . 

-  Failure:  The  I'JT  does  not  acknowledge  the  FIN  of  the 

REF  or  the  IUT  does  not  report  its  connection 
closed.  Also,  the  IUT  reports  its  connection 
closed  before  the  REF  closes.  The  RD  does  not 
correctly  interpret  CD  commands,  acknowledge  CD 
commands,  or  format  IUT  responses. 


TEST  7:  CLOSING  HANDSHAKE  WHEN  IUT  PEER  INITIATES  CLOSE 


Does  the  IUT  correctly  perform  the  closing  handshake  when  its 
peer  initiates  closing? 

-  Action:  The  LSD  performs  a  close.  When  the  IUT  reports 
receiving  the  REF's  closing,  it  performs  a 
close . 


-  Verification:  Ensure  that  the  RD  correctly  reports 

CLOSING  and  TERMINATE:  CONNECTION  CLOSED  when 
it  receives  these  responses  from  the  IUT  for 
the  REF's  closing  and  the  final  closing  of  the 
connection.  Check  the  TCP  segments  collected 
from  the  REF  to  determine  that  the  IUT  did  not 
send  its  FIN  before  being  instructed  to  close 
by  the  RD.  Also  check  that  the  IUT  sends  a  FIN 
to  the  REF  once  it  has  been  instructed  to 
close . 

-  Success:  The  IUT  waits  to  be  instructed  to  close  before 

it  sends  a  FIN.  It  sends  a  FIN  when  it  is 
instructed  to  close.  The  IUT  correctly  reports 
its  peer's  closing  and  the  closing  of  the 
connection.  The  RD  correctly  interprets 
Central  Driver  commands,  acknowledges  CD 
commands,  and  formats  IUT  responses. 

-  Failure:  The  IUT  sends  a  FIN  in  response  to  a  peer's 

FIN  before  it  is  instructed  to  close;  or  the 
IUT  does  not  send  a  FIN  when  it  is  instructed 
to  close.  Failure  also  occurs  when  the  IUT 
does  not  report  a  peer's  closing  or  the  closing 
of  the  connection;  and  if  the  RD  does  not 
correctly  interpret  CD  commands,  acknowledge  CD 
commands,  or  format  IUT  responses. 


TEST  8:  ABILITY  TO  RECONNECT  TO  COMMAND  CHANNEL  AFTER  CLOSURE 


Does  the  IUT  Remote  Driver  remain  listening  after  the  Central 
Driver  closes  the  command  channel? 

-  Action:  The  Central  Driver  instructs  the  Remote  Driver 
to  kill  itself.  After  waiting  five  seconds  to 
allow  the  connection  to  be  cleared,  the  CD 
attempts  to  reconnect  the  command  channel  to 
the  RD. 
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-  Verification:  If  the  scenario  aborts  when  the  CD 

attempts  to  reconnect  the  command  channel  to 
the  RD,  the  RD  is  no  longer  listening.  If  the 
CD  is  able  to  reconnect  the  command  channel,  a 
Remote  Driver  is  left  listening  after  the 
command  channel  is  closed. 


-  Success:  A  Remote  Driver  is  left  listening  when  the 

Central  Driver  closes  the  command  channel  to 
the  Remote  Driver,  and  reconnection  to  the 
Central  Driver  occurs. 

-  Failure:  A  Remote  Driver  is  not  left  listening  when  the 

Central  Driver  closes  the  command  channel  to 
the  Remote  Driver.  The  RD  does  not  correctly 
interpret  CD  commands,  acknowledge  CD  commands, 
or  format  IUT  responses. 


Scenario  OPEN 


Scenario  OPEN  tests  the  TCP  implementation  of  Fully  Specified 
Passive  Open,  and  Active  Open  with  Data. 

TEST  9:  FULLY  SPECIFIED  PASSIVE  OPEN 


Does  the  IUT  implement  a  Passive  Open  that  accepts  an  Active  Open 
request  only  from  a  specified  address? 

-  Action:  RD  performs  a  Fully  Specified  Passive  Open. 

LSD  does  an  Active  Open  to  it  from  a  socket 
bound  with  the  specified  address. 

-  Verification:  Determine  that  a  connection  was  made  by 

finding  an  OPEN  SUCCESS  response  from  the  LSD. 

-  Success:  The  connection  was  made. 

-  Failure:  Connection  was  not  made. 


TEST  10:  FULLY  SPECIFIED  PASSIVE  OPEN 


Will  the  IUT  Fully  Specified  Passive  Open  accept  an  Active  Open 
request  from  an  unspecified  port? 

-  Action:  RD  performs  a  Fully  Specified  Passive  Open. 

LSD  does  an  Active  Open  to  it  from  a  socket 
with  a  port  number  different  from  the  one 
specified  in  the  Fully  Specified  Passive  Open. 

-  Verification:  Determine  that  a  connection  was  made  by 

checking  that  the  REF  sent  an  OPEN  FAILURE 
response . 

-  Success:  Connection  was  not  made. 

-  Failure:  Connection  was  made. 


TEST  11:  ACTIVE  OPEN  WITH  DATA 


Does  the  IUT  send  data  on  its  SYN  segment  on  an  Active  Open  with 
Data? 

-  Action:  RD  performs  an  Active  Open  with  Data. 

-  Verification:  Check  the  IUT's  SYN  segment  to  see  if 

data  was  sent  on  that  segment. 

-  Success:  The  IUT  sends  data  on  its  SYN  segment. 

-  Failure:  The  IUT  does  not  send  data  on  its  SYN  segment. 


TEST  12:  ACTIVE  OPEN  WITH  DATA 


Does  the  IUT  acknowledge  data  received  on  the  SYN  segment  in  its 
SYN  ACK  (before  connection  establishment'? 

-  Action:  LSD  performs  an  Active  Open  with  Data. 

-  Verification:  Check  the  IUT  SYN  ACK  segment  to  ensure 

that  it  does  not  acknowledge  data. 

-  Success:  Data  is  not  acknowledged  on  the  IUT  SYN  ACK 

segment . 

-  Failure:  Data  is  acknowledged  on  the  IUT  SYN  ACK 

segment . 


TEST  13:  PORT  NUMBER  RANGE  3 


Can  the  IUT  assign  a  range  of  local  port 


-  Action:  RD  does  two  Passive  Open  requests:  one 

specifies  source  port  1  and  the  other  specifies 
source  port  65535.  The  RD  also  does  an  Active 
Open  to  destination  port  65534. 


-  Verification:  Determine  whether  the  IUT  returns  SYSTEM 

ERROR:  REQUESTED  SOURCE  PORT  NOT  PERMITTED  or 

the  OPEN  ID  from  the  Passive  Open  requests. 
Ensure  that  a  connection  was  made  when 
destination  port  65534  was  specified  in  the 
Active  Open. 

-  Observation:  Result  is  to  indicate  the  range  of  port 

numbers  that  the  IUT  allows  to  be  assigned. 


TEST  21:  MISMATCHED  PRECEDENCE 


Does  the  IUT  provide  the  option  to  set  a  precedence  value  for  the 
connection  and  make  correct  checks  of  the  precedence  of  incoming 
segments  to  the  connection? 

-  Action:  RD  passively  opens  a  connection  with  maximum 

precedence.  LSD  actively  opens  at  a  less  than 
maximum  precedence  and  REF  does  not  raise  its 
precedence . 

-  Verification:  Determine  that  IUT  sets  the  precedence 

option  by  checking  the  segments  output  by  the 
IUT.  Ensure  that  IUT  aborts  the  connection 
when  REF  does  not  match  precedence  by  looking 
for  TERMINATE:  REMOTE  ABORT  from  the  LSD  or  an 
OPEN  FAILURE  from  the  LSD  connection. 

-  Success:  IUT  sets  precedence  option  and  aborts 

connection  when  peer's  precedence  does  not 
match. 

-  Failure:  IUT  does  not  set  precedence  option  or  makes 

connection  when  precedence  does  not  match. 
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TEST  22:  PRECEDENCE 


Does  the  IUT  provide  the  option  to  set  precedence  for  the 
connection  and  make  correct  checks  on  the  incoming  segments  to 
the  connection? 

-  Action:  RD  passively  opens  a  connection  with  maximum 

precedence.  LSD  actively  opens  at  a  less  than 
maximum  precedence.  The  REF  raises  its 
precedence  during  the  opening  handshake. 


-  Verification:  Determine  that  the  connection  is  made  by 

checking  that  the  LSD  reports  an  OPEN  SUCCESS. 
Check  the  IUT  segments  to  ensure  that 
precedence  was  set. 

-  Success:  The  IUT  makes  the  connection  and  sets 

precedence . 

-  Failure:  The  IUT  does  not  set  precedence  or  does  not 

make  the  connection,  even  though  the  REF 
matched  its  precedence. 


TEST  23:  PRECEDENCE  NEGOTIATION 


Does  the  IUT  provide  the  option  to  set  precedence  for  the 
connection  and  raise  its  own  precedence  to  match  its  peer's 
precedence? 

-  Action:  LSD  passively  opens  a  connection  with  a  given 

precedence.  The  RD  opens  with  a  zero 
precedence . 

-  Verification:  Determine  that  the  connection  is  made  by 

checking  that  the  LSD  reports  an  OPEN  SUCCESS. 
Check  the  IUT  segments  to  ensure  that 
precedence  was  raised. 

-  Success:  The  !  L'T  makes  the  connection  and  sets 

precedence . 

-  Failure:  The  !UT  does  not  raise  precedence  to  match  the 

precedence  of  the  REF. 
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TEST  24 :  STATUS 


Does  the  IUT  in  its  status  response  correctly  report  a 
connection's  source  port,  destination  port,  destination  address 
window,  precedence,  and  state?  (These  fields  were  selected  to 
represent  both  static  and  dynamic  internal  information.) 

-  Action:  The  RD  asks  the  IUT  to  give  the  status  of  a 

connection . 

-  Verification:  Ensure  that  the  status  response  given 

matches  the  true  status  of  the  connection. 

-  Success:  The  IUT  reports  the  status  of  the  connection 

cor  rectly . 

-  Failure:  The  IUT  does  not  report  the  status  of  the 

connection  correctly. 


Scenario  CLOSE 


Scenario  CLOSE  tests  the  TCP  implementation  of  graceful 
closings,  its  handling  of  aborts,  precedence,  and  status. 

TEST  14:  DATA  TRANSFER  IN  CLOSING  STATES 

Does  the  IUT  provide  graceful  closing  by  completing  data 
transfer  after  its  Upper  Level  Protocol  has  initiated  closing? 

-  Action:  The  RD  sends  a  large  amount  of  data  and 

immediately  closes. 

-  Verification:  Determine  that  the  REF  receives  all  the 

data  the  IUT  was  requested  to  send. 

-  Success:  All  expected  data  was  received  by  the  REF. 

-  Failure:  All  expected  data  not  received  by  REF. 


TEST  15:  DATA  TRANSFER  IN  CLOSING  STATES 


Does  the  IUT  provide  graceful  closing  by  continuing  to  send  data 
after  receiving  peer's  FIN  segment? 

-  Action:  The  IUT  is  instructed  to  send  data  after  it 

has  received  its  peer's  closing  FIN  segment. 

-  Verification:  Determine  that  the  IUT  sends  the  data  by 

checking  that  all  expected  data  is  received  by 
the  REF. 

-  Success:  REF  receives  all  data  IUT  was  asked  to  send. 

-  Failure:  REF  does  not  receive  all  data  IUT  was  asked  to 

send . 


TEST  16:  DATA  TRANSFER  IN  CLOSING  STATES 

Does  the  IUT  deliver  data  sent  after  it  has  initiated  closing? 

-  Action:  RD  tells  IUT  to  close.  On  receiving  the  IUT's 

close,  the  LSD  requests  the  REF  to  send  data 
to  the  IUT. 

-  Verification:  Determine  that  the  IUT  delivers  all  the 

data  sent  by  the  REF. 

-  Success:  IUT  delivers  all  data  sent  by  REF. 

-  Failure:  IUT  does  not  deliver  all  data  sent  by  REF. 


TEST  17:  UPPER  LAYER  PROTOCOL  ABORT 


Does  the  IUT  perform  an  Upper  Layer  Protocol  (ULP)  abort  by 
sending  a  correct  reset  segment? 

-  Action:  RD  aborts  the  connection. 

-  Verification:  Check  that  the  LSD  reports  a  TERMINATE: 

REMOTE  ABORT  response  and  the  RD  reports 

TERMINATE:  ULP  ABORT  or  TERMINATE:  USER  ABORT. 


-V  * 
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-  Success:  The  IUT  sends  a  reset  segment  and  the  correct 

terminate  response. 

-  Failure:  The  IUT  does  not  send  a  reset  segment  or 

correct  terminate  response. 


TEST  18:  PEER  ABORT 


Can  the  IUT  detect  its  peer's  abort? 

-  Action:  The  LSD  instructs  its  REF  to  abort  connection. 

-  Verification:  Check  that  the  IUT  reports  TERMINATE: 

REMOTE  ABORT. 

-  Success:  IUT  correctly  reports  REMOTE  ABORT. 

-  Failure:  IUT  does  not  correctly  report  its  peer's 

abort. 


TEST  19:  UPPER  LAYER  PROCESS  ABORT 


Does  the  IUT  discard  data  queued  for  sending  when  it  performs  a 
ULP  abort? 

-  Action:  RD  sends  data  to  its  peer  and  then  immediately 

aborts  the  connection. 

-  Verification:  Check  that  the  LSD  reports  a  TERMINATE: 

REMOTE  ABORT  response  and  the  RD  reports 
TERMINATE:  ULP  ABORT.  Examine  the  IUT  reset 
segment  for  correctness  and  determine  if  all 
data  sent  by  the  RD  was  received  by  the  LSD. 

-  Success:  The  IUT  sends  the  correct  terminate  response, 

its  reset  segment  is  correctly  formatted,  and 
not  all  data  sent  by  the  IUT  is  received  by 
the  REF. 

-  Failure:  The  IUT  sends  an  incorrect  terminate  response 

or  an  incorrect  reset  segment. 

-  Inconclusive:  If  the  LSD  receives  all  data,  this  test 

is  inconclusive  because  the  IUT  may  already 
have  sent  the  data  before  receiving  the  abort 
command . 


TEST  20: 


PEER  ABORT 


Does  the  IUT  detect  its  peer's  abort  and  then  discard  data  queued 
for  sending? 

-  Action:  The  LSD  instructs  its  REF  to  abort  while  the 

IUT  is  sending  data. 

-  Verification:  Check  that  the  IUT  reports  TERMINATE: 

REMOTE  ABORT  and  that  the  IUT  stops  sending 

data  after  receiving  the  peer's  abort. 

-  Success:  IUT  correctly  reports  REMOTE  ABORT  and  stops 

sending  data  after  receiving  its  peer's  reset. 

-  Failure:  IUT  does  not  correctly  report  its  peer's 

abort . 

-  Inconclusive:  If  the  LSD  receives  all  the  data  sent, 
this  test  is  inconclusive  because  the  IUT  may  already  have  sent 
the  data  before  receiving  the  abort  Command. 


Scenario  RELIABILITY 

Scenario  RELIABILITY  tests  the  TCP  implementation's  ability  to 
maintain  data  integrity:  out-of-order  data,  overlapping  data, 
lost  data,  segments  with  bad  checksums,  and  segments  with 
sequence  number  wraparound. 

TEST  25:  OUT-OF-ORDER  DATA 


Can  the  IUT  correctly  handle  segments  that  arrive  out  of  order, 
as  indicated  by  their  sequence  numbers? 

-  Action:  The  LSD  sends  data  to  the  IUT.  The  REF 

divides  the  data  into  segments  and  outputs 
them  out  of  order. 

-  Ver 1 f  icat ion :  Determine  if  the  IUT  delivers  the  data  in 

the  correct  order. 

-  Success:  The  IUT  correctly  reorders  the  data. 

-  Failure:  The  IUT  does  not  correctly  reorder  the  data. 
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TEST  26:  OVERLAPPING  DATA 


Can  the  IUT  clean  up  overlapping  data? 

-  Action:  The  LSD  sends  data  to  the  IUT.  The  REF 

repackages  the  data  for  retransmission  so  that 
some  segments  contain  both  new  data  and  data 
already  sent. 

-  Verification:  Determine  that  IUT  accepts  the  data  and 

correctly  delivers  it. 

-  Success:  The  IUT  is  able  to  accept  the  overlapping  data 

and  deliver  it  correctly. 

-  Failure:  The  IUT  does  not  deliver  the  data  on  segments 

after  the  first  arrival  or  delivers  the  data 
1 ncor  rect ly . 


TEST  27:  LOST  DATA 


Can  the  IUT  detect  that  data  is  lost? 

-  Action:  The  LSD  sends  data  to  the  RD.  The  REF  divides 

the  data  into  several  segments  and  sends  data, 
omitting  a  segment.  The  missing  segment  is 
not  sent  until  the  last  segment  sent  is 
retransmitted  several  times. 

-  Verification:  Determine  that  the  IUT  does  not 

acknowledge  anything  sent  after  this  missing 
segment  until  the  missing  segment  is 
t  r ansm  1 1  ted . 

-  Success:  The  IUT  does  not  acknowledge  any  data  received 
after  the  last  correctly  ordered  segment, 
until  the  missing  segment  is  sent. 

The  : UT  acknowledges  data  sent  after  the 
miss: no  seamen t  before  the  missing  segment  is 


F  a l lure: 


TEST  28:  CHECKSUM 


Does  the  IUT  detect  a  segment  with  a  bad  checksum  and  discard  it? 

-  Action:  The  LSD  sends  data  to  the  IUT.  The  REF  sends 

out  a  segment  with  a  bad  checksum  and 
retransmits  it  incorrectly  several  times 
before  transmitting  it  correctly. 

-  Verification:  Determine  that  the  IUT  acknowledges  only 

the  segments  sent  with  a  good  checksum  by 
checking  segment  data  collected  by  the  REF. 

-  Success:  The  IUT  acknowledges  only  segments  sent  with 

good  checksums. 

-  Failure:  The  REF  acknowledges  segments  sent  with  bad 

checksums . 


TEST  29:  ~FQUENCE  NUMBER  WRAPAROUND 


Does  the  IUT  use  correct  module  arithmetic  when  comparing 
sequence  numbers? 

-  Action:  The  LSD  sends  data  to  the  IUT.  The  REF  uses 

as  its  initial  sequence  number  a  number  guar¬ 
anteed  to  cause  wraparound  from  2  *  *  3  2  —  1  to  0 
on  the  data  segments. 

-  Verification:  Determine  if  the  IUT  acknowledges  all 

data  sent  by  the  REF. 

-  Success:  The  IUT  acknowledges  the  data  sent  by  the  RFF. 

-  Failure:  The  IUT  does  not  acknowledge  any  data  sent  by 

the  REF  after  the  sequence  number  wraparound 
occurs . 


Scenario  MULTIPLEX 


Scenario  MULTIPLEX  tests  how  well  the  TCP  implementation  can 
establish  multiple  connections  and  demultiplex  data  sent  over 
these  connections.  A  TCP  connection  is  defined  by  the  source 
port,  source  address,  destination  port,  and  destination  address 
of  the  connection.  This  four-element  identification  is  known  as 
a  4-tuple.  Scenario  MULTIPLEX  tests  by  opening  multiple 
connections  with  different  combinations  in  the  4-tuple  (from  the 
viewpoint  of  the  IUT). 

TEST  30:  MULTIPLEX  DATA  OVER  2  CONNECTIONS  WITH  UNIQUE  4-TUPLES 


Can  the  IUT  correctly  deliver  data  sent  over  2  connections  it 
actively  opened,  with  no  4-tuple  element  in  common? 

-  Action:  The  RD  opens  2  connections  to  the  LSD.  The 

LSD  then  sends  unique  data  over  each 
connection . 

-  Verification:  Determine  that  the  IUT  keeps  separate  the 

data  sent  on  each  connection  and  delivers  it 
correctly. 

-  Success:  The  IUT  delivers  the  data  sent  over  each 

connection  correctly. 

-  Failure:  The  IUT  does  not  deliver  the  data  sent  over 

each  connection  correctly. 


TEST  31:  MULTIPLEX  OVER  2  CONNECTIONS  WITH  COMMON  DESTINATION 
-  PQRT  in  4 -TUPLES 

Can  the  IUT  multiplex  dafa  over  2  Conner-*- i  ^ne  that  share  a  common 
destination  port  in  their  4-tuples? 

-  Action:  Two  connections  are  opened  that  have  the  same 

destination  port  on  the  REF.  The  LSD  sends 
unique  data  over  each  connection. 

-  Verification:  Determine  that  the  IUT  keeps  separate  the 

data  received  over  each  connection  and 
delivers  it  correctly. 


-  Success:  The  IUT  correctly  delivers  the  data  sent  over 

each  connection. 

-  Failure:  The  IUT  does  not  deliver  the  data  sent  over 

each  connection  correctly. 

TEST  32:  MULTIPLEX  WITH  2  CONNECTIONS  HAVING  SAME  REF  SRC  PORT 
-  IN  4-TUPLES 

Can  the  IUT  multiplex  data  over  2  connections  that  have  the  same 
destination  port  in  their  4-tuples? 

-  Action:  The  LSD  actively  opens  2  connections  from  the 

same  source  port  to  distinct  listening  ports 
on  the  IUT.  The  LSD  then  sends  unique  data  to 
the  RD  over  each  connection. 

-  Verification:  Determine  that  all  the  data  sent  by  the 

LSD  is  delivered  correctly  to  the  RD. 

-  Success:  All  sent  data  is  delivered  correctly  to  the 


-  Failure:  Data  is  not  delivered  correctly  to  the  RD. 


TEST  33:  MULTIPLEX  DATA  OVER  2  CONNECTIONS  WITH  UNIQUE 
-  4 -TUPLES 

Can  the  IUT  correctly  deliver  data  sent  over  2  connections  that 
the  IUT  passively  opens,  when  the  connections  have  no  4-tuple 
elements  in  common? 

-  Action:  The  LSD  opens  2  connections  to  the  RD.  The 

LSD  then  sends  unique  data  data  over  each 
connect  ion . 

-  Verification:  Determine  that  the  IUT  keeps  separate  the 

data  sent  on  each  connection  and  delivers  it 
correctly. 

-  Success:  The  IUT  delivers  the  data  sent  over  each 

connection  correctly. 

-  Failure:  The  IUT  does  not  deliver  the  data  sent  over 

each  connection  correctly. 


TEST  34:  MULTIPLEX  DATA  OVER  3  CONNECTIONS  WITH  SAME  SRC 
-  PORT  IN  4 -TUPLE 

Can  the  IUT  correctly  establish  connections  and  demultiplex  data 
when  the  same  IUT  source  port  is  in  the  4-tuple  of  3  connections' 

-  Action:  The  LSD  actively  opens  3  connections  to  the 

same  IUT  port.  The  LSD  then  sends  unique  data 
to  the  RD  over  each  connection. 


-  Verification:  Determine  that  all  3  connections  are 

opened  and  that  all  the  data  sent  over  each 
connection  is  correctly  delivered. 

-  Success:  All  the  data  sent  over  the  3  connections  is 

correctly  delivered. 

-  Failure:  The  data  sent  over  the  3  connections  is  not 

correctly  delivered. 


TEST  35:  IUT  REJECTS  DUPLICATE  CONNECTION 


Does  the  IUT  reject  an  attempt  to  make  a  duplicate  connection  to 
its  listening  port? 


Action : 


The  LSD  actively  opens  2  connections  to  the 
IUT  from  different  ports.  The  LSD  then 
attempts  to  make  a  third  connection  using  the 
same  source  and  destination  port  used  in  the 
second  connection. 


-  Verification:  Determine  that  IUT  refuses  to  make  the 
duplicate  connection  (OPEN  FAILURE  response 
received  by  LSD),  and  does  not  enter  into  the 
opening  handshake  for  the  duplicate 
connect  ion . 


Success 


[ 


The  IUT  rejects  the  duplicate  connection  and 
does  not  enter  into  the  opening  handshake  for 
that  connection. 


Failure: 


The  IUT  fails  to  reject  the  duplicate 
connect  ion . 


TEST  36:  MULTIPLEX  DATA  OVER  CONNECTIONS  USING  THE  SAME  SEQUENCE 
-  NUMBERS 

Can  the  IUT  multiplex  data  when  the  REF  uses  the  same  sequence 
number  on  2  connections  ? 

-  Action:  The  LSD  opens  3  connections  to  the  IUT  and 

sends  unique  data  over  the  3  connections  to 
the  RD.  The  REF  ensures  that  the  the  TCP 
segments  on  2  of  the  connections  have  the  same 
sequence  number. 

-  Verification:  Determine  that  all  the  data  sent  over 

each  connection  is  correctly  delivered  to  the 
RD. 

-  Success:  All  the  data  sent  over  each  connection  is 

correctly  delivered. 

-  Failure:  The  data  sent  over  each  connection  is  not 

correctly  delivered. 


TEST  37:  IUT'S  REFUSAL  TO  MAKE  DUPLICATE  CONNECTION 


Does  the  IUT  refuse  to  make  a  duplicate  connection  when  it  is 
actively  opening? 

-  Action:  The  RD  makes  a  connection  to  the  LSD.  The  RD 

then  a t tempts  to  open  a  second  connection  with 
the  same  4-tuple  'same  source  and  destination 
ports1  . 

-  Ver l f icat  ion :  Verify  that  the  IUT  refuses  to  make  the 

duplicate  connection  by  responding  with  TCP 

ERROR:  CONNECTION  ALREADY  EXISTS  or  SYSTEM 
ERROR:  REQUESTED  SOURCE  PORT  IN  USE. 


Success : 


■s  '"ake  a  dup! irate  connection  and 

•  allocate  resources  for  a  duplicate 


Failure:  IUT  a..  ~ates  resources  for  a  duplicate 

•  :  'o  o  r  does  not  give  proper  response  t 
*  h>_-  attempt  to  open  the  duplicate  connection. 


Scenario  SECURITY 


Scenario  SECURITY  tests  the  TCP  Implementation  Under  Test  for 
basic  and  default  security.  It  tests  that  the  IUT: 

o  Allows  the  security  of  the  connection  to  be  set  by  the 
use  of  parameters  in  the  open  service  requests; 

o  Rejects  a  connect  ion  request  with  a  wrong  security 
level ; 

o  Aborts  the  connection  if  a  segment  arrives  with  any 
mismatch  of  the  security  option. 

Tests  38  through  46  test  basic  security.  Tests  47  through  50 
test  default  security.  Default  security  checks  should  be  per¬ 
formed  by  both  classified  and  unclassified  hosts.  If  the  IUT 
does  not  pass  Test  38  or  Test  39  (the  setting  of  security  in  the 
IUT  Active  Open  and  the  IUT  Passive  Open),  Tests  40  through  46 
are  not  executed. 


TEST  38:  IUT'S  ABILITY  TO  SET  SECURITY  IN  ITS  ACTIVE  OPEN 


Is  the  IUT  able  to  set  security  in  its  Active  Open? 

-  Action:  The  RD  opens  a  connection  with  the  classi¬ 

fication  and  protection  parameters  supplied 
for  the  IUT  Active  Open.  The  LSD  opens  with 
the  same  security  in  its  Passive  Open. 

-  Verification:  Determine  if  the  connection  is  opened 

successfully.  If  the  connection  is  opened, 
determine  that  the  security  parameters  have 
been  set  correctly.  If  the  open  service 
request  does  not  return  an  OPEN  ID,  the 
response  TCP  ERROR:  SEC/PREC  NOT  ALLOWED  or 
SYSTEM  ERROR:  REQUESTED  PARAMETER  NOT 
IMPLEMENTED  must  be  found. 


-  Failure:  Connection  is  not  established  and  neither  TCP 

ERROR:  SEC/PREC  NOT  ALLOWED  nor  SYSTEM  ERROR: 
REQUESTED  PARAMETER  NOT  IMPLEMENTED  is 

returned  from  the  IUT.  Connection  is 
established  but  the  parameters  have  not  been 
set  correctly. 


TEST  39:  IUT'S  ABILITY  TO  SET  SECURITY  PARAMETERS  IN  ITS 
-  PASSIVE  OPEN 

Is  the  IUT  able  to  set  security  in  its  Passive  Open  ? 

-  Action:  The  P.D  uses  the  classification  and  protection 

parameters  that  it  is  given  for  an  IUT  Passive 
Open.  The  LSD  sets  the  same  parameters  in  its 
Active  Open  and  attempts  to  open  a  connection. 

-  Verification:  Determine  that  the  connection  is 

established.  If  a  connection  is  opened 
successfully,  then  security  fields  in  the  TCP 
segments  are  checked  to  make  sure  that  the  IUT 
is  sett'ng  the  security  from  its  input 
parameter.  The  REF  collects  these  segments. 

If  a  connection  is  not  established,  check  that 
the  IUT  open  service  response  returned  the 
response  TCP  ERROR:  SEC/PREC  NOT  ALLOWED  or 
SYSTEM  ERROR:  REQUESTED  PARAMETER  NOT 
IMPLEMENTED. 

-  Success:  The  connection  is  established.  Analysis 
determines  that  the  security  parameters  were 
set  in  the  IUT  Passive  Open.  Also,  the 
connection  is  not  established  but  the  IUT 
returns  either  TCP  ERROR:  SEC/PREC  NOT  ALLOWED 
or  SYSTEM  ERROR:  REQUESTED  PARAMETER  NOT 
IMPLEMENTED  in  response  to  the  open  service 
request . 

Although  the  connection  is  established, 
analysis  reveals  that  the  IUT  is  not  setting 
security  but  merely  matching  peer's  security. 
Also,  the  connection  is  not  established  but  no 
proper  security-related  response  is  received 
to  the  open  service  request. 


Failure: 


put  parameter 
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-  Success:  The  IUT  successfully  gets  an  OPEN  FAILURE. 

-  Failure:  The  IUT  fails  to  get  an  OPEN  FAILURE. 


TEST  42:  SECURE  IUT  REJECTS  CONNECTION  ATTEMPT  OF  UNSECURED  PEER 


Does  the  secured  IUT  reject  connection  attempt  of  an  unsecured 
host? 

-  Action:  LSD  with  no  security  actively  opens  to  the 

IUT.  The  IUT  has  passively  opened  with 
secur i ty  set . 

-  Verification:  Determine  that  no  connection  is 

established  by  checking  for  an  OPEN  FAILURE 
response  from  the  REF. 

-  Success:  The  REF  gets  an  OPEN  FAILURE  or  the  IUT  cannot 

set  security  parameters. 

-  Failure:  The  connection  is  established. 


TEST  43:  SECURITY  OPTION  PLACEMENT  IN  DATA  SEGMENTS 


Is  the  IUT  consistent  in  its  security  option  placement  when 
sending  data? 

-  Action:  A  secure  connection  is  opened.  Both  the  LSD 

and  the  RD  send  data. 

-  Verification:  Determine  that  all  the  data  sent  by  the 

LSD  and  the  RD  is  correctly  delivered  by  the 
other  peer.  Check  the  segment  information 
collected  by  the  REF  to  ensure  that  the 
correct  security  was  placed  on  every  segment. 

-  Success:  All  data  is  delivered  and  the  security  is 

correct Ly  placed  on  each  TCP  segment. 

-  Failure:  All  data  is  not  correctly  delivered  or  the 

security  fields  are  not  correctly  placed  on 
everv  TCP  segment. 


TEST  44:  RESPONSE  TO  DATA  WITH  MISMATCHED  SECURITY  CLASS 


Does  the  IUT  reset  a  connection  on  receiving  data  with  a 
misma tched  security  class? 

-  Action:  A  secure  connection  is  established.  The  LSD 

sends  data  to  the  RD.  The  REF  places  a  wrong 
security  class  on  the  data  segments. 

-  Verification:  Determine  that  the  IUT  resets  connection 

by  checking  that  the  REF  reports  REMOTE  ABORT 
Check  that  the  IUT  reports  SEC/PREC  MISMATCH. 

-  Success:  The  IUT  resets  the  connection  and  reports 

SEC/PREC  MISMATCH. 

-  Failure:  The  IUT  fails  to  reset  connection  or  does  not 

report  SEC/PREC  MISMATCH. 


TEST  45:  RESPONSE  TO  DATA  WITH  MISMATCHED  PROTECTION  AUTHORITY 


Does  the  IUT  reset  a  connection  on  receiving  data  with  a 
mismatched  security  authority? 

-  Action:  A  secure  connection  is  established.  The  LSD 

sends  data  to  the  RD.  The  REF  places  an 
incorrect  protection  authority  on  the  data 
segments . 

-  Verification:  Determine  that  the  IUT  resets  the 

connection  by  checking  that  the  REF  reports 
REMOTE  ABORT.  Check  that  the  IUT  reports 

SEC/PREC  MISMATCH. 

-  Success:  The  IUT  resets  the  connection  and  reports 

SEC/PREC  MISMATCH. 

-  Failure:  IUT  r a : ! s  to  reset  connection  or  does  not 

report  SEC/PREC  MISMATCH. 


TEST  46:  RESPONSE  TO  DATA  WITH  AN  EXTRA  PROTECTION  AUTHORITY 


Does  the  IUT  reset  a  connection  on  receiving  data  with  an  extra 
security  protection  authority? 

-  Action:  A  secure  connection  is  established.  The  LSD 

sends  data  to  the  RD.  The  REF  places  an  extra 
protection  authority  on  the  data  segments. 

-  Verification:  Determine  that  the  IUT  resets  the 

connection  by  checking  that  the  REF  reports 
REMOTE  ABORT.  Check  that  the  IUT  reports 

SEC/PREC  MISMATCH. 

-  Success:  The  IUT  resets  the  connection  and  reports 

SEC/PREC  MISMATCH. 

-  Failure:  IUT  fai  !s  to  reset  connection  or  does  not 

report  SEC/PREC  MISMATCH. 

TEST  47:  USE  OF  SECURITY  OPTION  FOR  UNCLASSIFIED  CONNECTIONS 


Does  the  IUT  use  the  security  option  for  unclassified 
connect  ions? 

-  Action:  The  LSD  does  a  Passive  Open  with  security  set. 

The  RD  does  an  Active  Open  with  no  security 
set . 

-  Verification:  Check  TCP  segments  collected  by  the  REF 

to  determine  if  IUT  uses  the  security  option 
at  a  default  level  for  an  unsecured 
connection.  Ensure  that  the  connection  is  not 
opened  by  looking  for  the  OPEN  FAILURE 
response  from  the  IUT. 

-  Observation:  IUT  does  or  does  not  use  the  security 

option  for  unclassified  connections. 


-  Failure:  Test  connection  opened. 


TEST  48:  RECOGNITION  OF  UNCLASS  AND  GENSER  AS  EQUIVALENT  TO 
-  UNSECURE 

Does  the  unsecured  IUT  connect  with  a  peer  with  security  of 
UNCLASS  and  GENSER? 

-  Action:  LSD  does  a  passive  open  with  security  set  to 

UNCLASS  and  GENSER.  The  RD  does  an  active 
open  with  no  security  setting. 

-  Verification:  Determine  that  the  connection  is  opened  b\ 

looking  for  OPEN  SUCCESS  response  from  the 
IUT. 

-  Success:  Connection  established. 

-  Failure:  Connection  not  established. 


TEST  49:  UNSECURED  IUT  RESPONSE  TO  CONNECTION  ATTEMPT  BY  SECURE 
-  HOST 

Does  the  IUT  with  no  security  reject  an  Active  Open  from  a  peer 
with  security  set? 

-  Action:  RD  does  a  Passive  Open  with  no  security  set. 

The  LSD  does  an  Active  Open  with  security  set 
to  CONFID  and  DIA. 

-  Verification:  Determine  that  the  IUT  rejects  the 

connection  by  searching  for  OPEN  FAILURE 
response  reported  by  LSD. 

-  Success:  Connection  is  not  established. 

-  Failure:  Connection  established. 


TEST  50:  UNSECURED  IUT  RESPONSE  TO  DATA  MARKED  WITH  CLASSIFIED 
-  SECURITY 

Does  the  IUT  reset  connection  when  finding  data  marked  with 
security  higher  than  unclassified? 

-  Action:  A  connection  is  established  with  no  security 

settings.  The  LSD  sends  data  to  the  RD.  The 
REF  places  a  classified  security  option  on  a 
data  segment. 

-  Verification:  Determine  that  the  IUT  resets  the 

connection  and  reports  SEC/PREC  MISMATCH  to 
the  RD. 
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-  Success:  The  IUT  correctly  resets  connection  on  finding 

incorrectly  marred  security  on  data. 

-  Failure:  The  IUT  fails  to  recognize  wrong  security 

marking  on  data  and  does  not  reset  the 
connect  ion . 


Scenario  ALLOC 


Scenario  ALLOC  tests  the  TCP  implementation  for  its  ability  to 
perform  the  ALLOC  service  request  correctly  in  the  EXPLICIT  mode 
under  control  of  the  Central  Driver. 

TEST  5 1 :  ALLOC 


Can  the  IUT  perform  the  ALLOC  service  request  correctly? 

-  Action:  RD  and  LSD  establish  a  connection.  The  RD 

instructs  the  IUT  it  has  allocated  a  specified 
buffer  size  for  data.  Then  the  LSD  sends  data 
equal  to  twice  that  buffer  size  to  the  RD. 

-  Verification:  Determine  that  the  amount  of  data 
delivered  to  the  RD  by  the  IUT  is  not  greater 
than  that  specified  in  the  ALLOC  request.  If 
all  the  sent  data  is  acknowledged  prior  to  the 
RD's  sending  another  ALLOC,  the  amount  of  data 
delivered  must  be  equal  to  or  Less  than  the 
buffer  size  specified  in  the  ALLOC.  If  it  is 
necessary  for  the  RD  to  send  a  second  ALLOC 
for  ail  the  sent  data  to  be  acknowledged,  then 
results  are  determined  by  examining  the  TCP 
segments  collected  by  the  REF.  The  segments 
are  analyzed  to  make  sure  that  no  more  data 
was  acknowledged  than  was  specified  in  the 
ALLOC  before  the  IUT  receive  window  was  set  to 
zero . 

-  Success:  The  IUT  delivers  data  equal  to  or  less  than 
the  ALLCC  request. 

-  Failure:  The  IUT  del:  vers  more  data  than  AI.I.CC 
spec i f : es . 

-  Inconclusive:  Analysis  rannot  be  done  to  determine 
IUT's  performance. 
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Scenario  POLICY 


Scenario  POLICY  tests  the  TCP  implementation  of  maximum  segment 
size  option,  basic  retransmission,  and  ULP  timeout. 

TEST  52:  MAXIMUM  SEGMENT  SIZE  OPTION 


Does  the  IUT  use  the  maximum  segment  size  (MSS)  option  and 
respond  correctly  to  its  peer's  maximum  transmission  unit? 

-  Action:  The  LSD  and  the  RD  establish  a  connection. 

The  REF  places  a  low  MSS  on  its  opening 
segment.  The  RD  sends  data. 

-  Verification:  Check  segment  data  collected  by  the  REF 

to  see  if  IUT  uses  the  MSS  option.  Examine 
the  segment  data  to  see  if  the  IUT  sends  any 
data  segment  with  a  length  greater  than  the 
MSS  specified  by  the  REF. 

-  Success:  The  IUT  sends  segments  that  do  not  exceed  the 

maximum  segment  size  specified  by  the  REF. 

-  Failure:  IUT  sends  segments  that  exceed  the  maximum 

segment  size  specified  by  the  REF. 

-  Observation:  Observation  is  made  as  to  whether  the  IUT 

uses  the  MSS  option. 


TEST  53:  RETRANSMISSION  AFTER  ACKNOWLEDGMENT  OF  DATA 


Does  the  IUT  stop  retransmitting  promptly  after  receiving 
acknowledgment  of  data? 

-  Action:  The  !SP  a°d  *  ‘m  nr>  i  1  sh  a  '-onnprynn, 

The  Dn  sends  data.  The  LSI'  withholds 

ackn  wledgments  until  it  has  received  several 

transmissions  of  the  oldest  data. 

-  Verification:  Examine  the  TCP  segments  collected  by  th 

REF.  Count  the  number  of  retransmissions  of 
data  sent  after  the  data  is  acknowledged. 
Ensure  that  the  REE  receives  only  a  small 
number  of  retransmissions  after  it  has 
acknowledaed  data. 


-  Success:  The  IUT  does  no*,  rot  r  ar.sm  i t  after  data  is 

ackncw [edged . 

-  Failure:  IUT  does  not  stop  retransmitting  prompt  i  v 

cift.Gr  data  is  a c k n o w  i. o d o o d  . 

TEST  54:  RETRANSMISSION  AFTER  ACKNOWLEDGMENT  OF  SYN  AND  FIN 


Does  the  IUT  stop  retransmitting  promptly  after  its  SYN  and  FIN 
are  acknowledged? 

-  Action:  The  LSD  actively  opens  a  connection  to  the  RD 

The  REF  withholds  acknowledgments  of  the  IUT' 
SYN  segment  until  it  is  transmitted  several 
t ; mes .  Then  the  RD  closes  the  connection. 

Tne  REF  withholds  retransmissions  until  the 
lUT's  FIN  segment  is  transmitted  several 
t imes . 

-  Verification:  Examine  the  TCP  segments  collected  by  th 

REF.  Count  the  number  of  times  the  IUT  SYN 
segment  is  retransmitted  after  it  is 
acknowledged.  Count  the  number  of  times  the 
IUT  FIN  segment  is  retransmitted  after  it  is 
acknowledged.  Ensure  that  the  REF  receives 
only  a  small  number  of  retransmissions  after 
it  acknowledges  SYN  or  FIN. 

-  Success:  The  IUT  does  not  retransmit  its  SYN  and  FIN 

segments  after  they  are  acknowledged. 

-  Failure:  The  IUT  does  not  stop  retransmitting  its  SYN 

and  FIN  segments  promptly  after  they  are 
acknow ledged . 


TEST  55:  IMPLEMENTATION  OF  ULP  TIMEOUT  SERVICE  IN  ACTIVE  OPEN 


Does  the  IUT  implement  VI !  timeout  when  timeout  is  specified  in 
its  Active  Open? 

-  Action:  Find  the  number  of  retransmissions  by  the  IUT 

when  t  he  lUT's  defauLt  ULP  timeout  occurs  or 
when  the  defauit  timeout  of  2  minutes 
suggested  by  A  1 1. -STD-  1  ~,?3  is  reached.  This  i 
done  by  tponing  a  connection  and  having  the  R 
send  data.  The  RFF  does  not  acknowledge  the 
data.  When,  the  connection  is  aborted  '  or 


after  2  minutes),  check  the  TCP  segments 
collected  by  the  REF  and  count  the  number  of 
retransmissions  for  one  data  element.  This 
becomes  the  default  number  of  retransmissions . 
The  RD  does  an  Active  Open  with  a  small  ULP 
timeout  and  a  timeout  action  of  terminate  set. 
The  RD  then  sends  data.  The  REF  withholds 
acknowledgments.  The  test  continues  until  the 
connection  terminates  or  2  minutes  pass. 

-  Verification:  Check  the  TCP  segments  collected  by  the 

REF.  Count  the  number  of  times  a  data  element 
is  retransmitted.  The  number  of  retrans¬ 
missions  must  be  significantly  smaller  than 
the  default  number  of  retransmissions. 

-  Success:  IUT  implements  ULP  timeout  if  it  resets  the 

connection  and  the  number  of  data  retrans¬ 
missions  is  significantly  smaller  than  the 
default  number  of  retransmissions. 

-  Failure:  IUT  does  not  implement  ULP  timeout.  The  IUT 

does  not  reset  the  connection  or,  if  the 
connection  is  reset,  the  number  of  IUT 
retransmissions  indicates  that  the  abort  was 
caused  by  the  TCP  default  rather  than  by  the 
prescribed  ULP  timeout. 


TEST  56:  IMPLEMENTATION  OF  ULP  TIMEOUT  SERVICE  IN  SEND 


Does  the  IUT  implement  ULP  timeout  when  timeout  is  specified  in 
its  Send? 

-  Action:  The  RD  and  the  LSD  establish  a  connection. 

The  RD  sends  data  with  a  small  ULP  timeout  and 
a  timeout  action  of  terminate  set.  The  REF 
withholds  acknow ledgments .  The  test  continues 
until  the  connection  terminates  or  2  minutes 
pass . 


-  Verification: 


:>n:  Check  the  TCP  segments  collected  by  the 

REF.  Count  the  number  of  times  a  data  element 
is  retransmitted.  The  number  of  retrans¬ 
missions  must  be  significantly  smaller  than 
the  default  number  of  retransmissions  (deter¬ 
mined  in  Test  55 ) . 
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-  Success:  IUT  implements  ULP  timeout  if  it  resets  the 

connections  and  the  number  of  data  retrans¬ 
missions  is  significantly  smaller  than  the 
default  number  of  retransmissions. 

-  Failure:  IUT  does  not  implement  ULP  timeout.  The  IUT 

does  not  reset  the  connection  or,  if  the 
connection  is  reset,  the  number  of  IUT 
retransmissions  indicates  that  the  abort  was 
caused  by  the  TCP  default  rather  than  by  the 
prescribed  ULP  timeout. 


TEST  57:  IMPLEMENTATION  OF  ULP  TIMEOUT  SERVICE  IN  PASSIVE  OPEN 


Does  the  IUT  implement  ULP  timeout  when  timeout  is  specified  in 
its  Passive  Open? 

-  Action:  The  RD  does  a  Passive  Open  with  a  ULP  timeout 

set.  The  LSD  performs  an  Active  Open  and  a 
connection  is  established.  The  RD  then  sends 
data.  The  REF  withholds  acknowledgments.  The 
test  continues  until  the  connection  terminates 
or  2  minutes  pass. 

-  Verification:  Check  the  TCP  segments  collected  by  the 

REF.  Count  the  number  of  times  a  data  element 
is  retransmitted.  The  number  of  data  retrans¬ 
missions  must  be  significantly  smaller  than 
the  default  number  of  retransmissions 
(determined  in  Test  55). 

-  Success:  IUT  implements  ULP  timeout  if  it  resets  the 

connections  and  the  number  of  data  retrans¬ 
missions  is  significantly  smaller  than  the 
default  number  of  retransmissions. 

-  Failure:  IUT  does  not  implement  ULP  timeout.  The  IUT 

does  not  reset  the  connection  or,  if  the 
connection  is  reset,  the  number  of  IUT 
retransmissions  indicates  that  the  abort  was 
caused  by  the  TCP  default  rather  than  by  the 
prescribed  ULP  timeout. 


TEST  58:  IMPLEMENTATION  OF  ULP  TIMEOUT  NOTIFY  SERVICE 


Does  the  IUT  implement  a  ULP  timeout  where  the  timeout  action  is 
notify? 


-  Action:  The  RD  does  an  Active  Open  with  a  ULP  notify 

timeout  set  and  establishes  a  connection  with 
the  LSD.  The  RD  sends  data.  The  REF 
withholds  acknowledgments  on  the  data.  The 
test  continues  until  the  connection 
terminates  or  2  minutes  pass. 

-  Verification:  Check  that  the  RD  reports  the  TCP  ERROR 

message  ULP  NOTIFY. 

-  Success:  IUT  implements  ULP  notify. 

-  Failure:  IUT  does  not  implement  ULP  notify. 


Scenario  OUT  OF  BAND 

Scenario  OUT_OF_BAND  tests  the  TCP  implementation  of  zero  window, 
urgent  data,  and  pushed  data. 

TEST  59:  RESPONSE  TO  ZERO  WINDOW 


Does  the  IUT  correctly  respond  to  a  peer's  zero  window? 

-  Action:  A  connection  is  established  between  the  LSD 

and  the  RD.  The  RD  sends  data  to  the  LSD. 
The  REF  acknowledges  the  first  data  segment 
but  announces  a  zero  window  in  this 
acknowledgment . 

-  Verification:  Check  the  TCP  segments  collected  by  the 

REF  for  the  amount  of  data  sent  by  the  IUT 
while  the  REF  had  a  zero  window.  The  IUT 
should  not  send  more  than  one  byte  of  data 
while  the  REF  has  a  zero  window. 

-  Success:  The  IUT  sends  no  segment  of  length  greater 

than  1  while  its  peer  has  a  zero  window. 


Failure: 


The  IUT  sends  a  segment  of  length  greater 
than  1  while  its  peer  has  a  zero  window. 


TEST  60:  IMPLEMENTATION  OF  URGENT  SERVICE 


Does  the  IUT  set  the  urgent  flag  and  urgent  pointer  when 
requested  to  send  urgent  data? 

-  Action:  The  LSD  and  the  RD  establish  a  connection. 

The  RD  sends  urgent  data  to  the  LSD. 

-  Verification:  Check  the  TCP  segment  information 

collected  by  the  REF  to  ensure  that  the  IUT 
sets  the  urgent  flag  on  every  segment  of  the 
data.  Also  check  that  the  value  of  the 
urgent  pointer  on  these  segments  equals  the 
amount  of  urgent  data  that  exists  between  the 
first  sequence  number  of  the  segment  to  the 
end  of  the  urgent  data. 

-  Success:  The  IUT  correctly  sets  the  urgent  flag  and 

urgent  pointer  on  urgent  data. 

-  Failure:  The  IUT  does  not  correctly  set  the  urgent 

flag  or  urgent  pointer  on  urgent  data. 


TEST  61:  URGENT  SERVICE  WHEN  PEER  HAS  ZERO  WINDOW 


Does  the  IUT  handle  urgent  correctly  when  its  peer  has  a  zero 
window? 


-  Action:  The  LSD  and  the  RD  establish  a  connection. 

The  RD  sends  normal  data  and  then  urgent  data 
to  the  LSD.  The  REF  sets  its  receive  window 
to  zero  when  it  acknowledges  the  first  IUT 
segment.  The  REF  opens  its  window  again 
later  in  the  data  transfer. 

-  Verification:  Check  the  TCP  segments  collected  by  the 

REF.  Ensure  that,  while  the  REF  is  showing  a 
zero  window,  the  IUT  sends  segments  with  the 
urgent  flag  set.  The  value  of  the  urgent 
pointer  is  set  to  the  number  of  bytes  of 
urgent  data  to  be  sent,  and  the  length  is  no 
greater  than  1. 


-  Success:  The  IUT  sends  one-byte  probe  segments  and 

correctly  sets  the  urgent  flag  and  urgent 
pointer  in  them. 

-  Failure:  The  IUT  does  not  send  one-byte  probe  segments 

although  urgent  data  is  present,  or  it  does 
not  correctly  set  the  urgent  flag  or  urgent 
pointer  in  the  probe  segments  it  sends. 


TEST  62:  DIFFERENTIATION  BETWEEN  URGENT  AND  NON-URGENT  DATA 


Is  the  IUT  abl  -  to  deliver  urgent  data? 

-  Action:  The  LSD  and  the  RD  establish  a  connection. 

The  LSD  sends  one  byte  of  urgent  data  to  the 
RD.  It  then  sends  the  RD  some  bytes  of  non¬ 
urgent  data. 

-  Verification:  Evaluate  the  DELIVER  responses  from  the 

RD.  The  urgent  data  must  be  delivered  in  a 
separate  DELIVER  from  the  non-urgent  data. 

-  Success:  The  RD  DELIVER  responses  show  the  one  bote  of 

urgent  data  delivered  separately  from  the 
subsequent  non-urgent  data. 

-  Failure:  The  RD  DELIVER  responses  do  not  show  the  one 

byte  of  urgent  data  delivered  separately  from 
the  subsequent  non-urgent  data. 


TEST  63:  PUSH  SERVICE  WHEN  NOT  REQUESTED 


Does  the  IUT  push  data  when  not  requested  to  do  so? 

-  Action:  The  13!'  and  the  RD  establish  a  connection. 

The  R I  sends  data  to  the  LSD.  It  does  not 
rogues'  that  the  data  be  pushed. 

-  Verification:  Exam  me  the  TCP  segments  collected  by  the 

REF.  1' 'ho  push  flag  should  not  be  set  on  an}' 

segments  sent  by  the  IUT,  except  possibLy  the 
last  data  segment.  (It  is  permissible  for 
the  IUT  to  set  a  push  flag  on  the  very  last 
data  segment  sent,  't 


-  Success:  The  IUT  correctly  does  not  push  any  data  or 

the  IUT  pushes  only  the  last  data  segment. 

-  Failure:  The  IUT  incorrectly  sets  push  flags  on  data 

not  requested  to  be  pushed. 


TEST  64:  PUSH  SERVICE  ON  REQUEST 


Is  the  IUT  able  to  push  data  on  request? 

-  Action:  The  LSD  and  the  RD  establish  a  connection. 

The  RD  sends  some  bytes  of  data  with  a  push 
indication.  It  then  sends  data  without  the 
push  indication. 

-  Verification:  Examine  the  TCP  segments  collected  by  the 

REF.  The  first  data  segment  the  IUT  sends 
should  have  the  push  flag  set  and  should 
contain  at  least  the  number  of  bytes  of  data 
sent  with  the  push  indication.  The  only 
other  segment  that  could  have  a  valid  push 
flag  is  the  last  data  segment. 

-  Success:  The  IUT  correctly  sets  push  flag  only  on 

pushed  data  and  possibly  the  last  data 
segment . 

-  Failure:  The  IUT  fails  to  set  push  flag  on  pushed  data 

or  sets  push  flag  on  unpushed  data. 

-  Observation:  The  IUT  allows  its  Upper  Level  Protocol 

( ULP )  to  request  rather  than  command  push 
service.  This  observation  is  made  when  the 
segment  with  the  push  flag  carries  more  than 
the  pushed  data. 


Scenario  RESET 


Scenario  RESET  tests  whether  the  TCP  implementation  does  correct 
reset  processing  by  testing  the  common  reset  conditions. 


TEST  65:  RESPONSE  TO  CONNECTION  REFUSAL 


Does  the  IUT  respond  correctly  to  connection  refusal? 


-  Action:  The  RD  actively  opens.  There  is  no  listening 

process  at  the  destination  port  of  its  Active 
Open . 

-  Verification:  Determine  that  the  PP  receives  an  OPEN 

FAILURE  response  from  the  IUT. 

-  Success:  The  TUT  reports  an  OPEN  FAILURE. 

-  Failure:  The  IUT  does  not  report  an  OPEN  FAILURE. 


TEST  66:  PARTIAL  RESET  PRIOR  TO  CONNECTION  ESTABLISHMENT 


Does  the  IUT  continue  listening  after  receiving  a  reset  during 
connection  establishment? 

-  Action:  The  RD  initiates  a  Passive  Open.  The  LSD 

actively  opens.  On  receipt  of  the  IUT's  SYN 
ACK,  the  REF  resets  the  connection.  The  LSD 
attempts  to  open  the  connection  again. 

-  Verification:  Determine  that  the  LSD  reports  an  OPEN 

SUCCESS  response  from  the  PEF  on  the  second 
connection . 

-  Success:  The  second  connection  is  established. 

-  Failure:  The  second  connection  cannot  be  established. 


TEST  67:  RESPONSE  TO  RESET  RCVD  WHILE  SENDING  DATA  OVER 
-  CONNECTION 

Does  the  IUT  abort  with  the  correct  responses  when  its  peer 
aborts  while  the  IUT  is  sending  data  over  a  connection? 

-  Action:  The  LSD  and  the  RD  establish  a  connection. 

The  RD  sends  data.  The  REF  resets  the 
connection  when  it  receives  the  first  IUT 
data  segment. 

-  Verification:  Determine  that,  after  the  reset,  the  RD 

reports  the  response  TERMINATE:  REMOTE  ABORT 
from  the  IUT  and  the  LSD  reports  the  response 

TERMINATE:  SERVICE  FAILURE  from  the  REF. 


-  Success:  The  correct  TERMINATE  responses  are  reported 

from  both  the  IUT  and  the  REF. 

-  Failure:  The  correct  TERMINATE  responses  are  not 

received  from  the  IUT  and  the  REF. 


TEST  68:  RESET  FORMAT  RESPONDING  TO  ACTIVE  OPEN  WITHOUT 
-  LISTENING  PORT 

Does  the  IUT  send  a  correct  reset  segment  on  receipt  of  a  SYN  for 
a  non-existent  port? 

-  Action:  The  LSD  initiates  an  Active  Open  to  a  port  on 

the  IUT  without  a  listening  process. 

-  Verification:  Check  the  TCP  segments  collected  by  the 

REF.  The  IUT  reset  segment  must  have  the 
format:  sequence  number  =  0,  acknowledgment 
number  =  the  sequence  number  of  the  REF’s  SYN 
segment  +1;  also,  the  ACK  and  RESET  flags 
must  be  set. 

-  Success:  The  IUT  uses  correct  reset  segment  format. 

-  Failure:  The  IUT  uses  incorrect  reset  segment  format. 


TEST  69:  RESET  FORMAT  RESPONDING  TO  ACTIVE  OPEN  WITH  DATA 
-  WITHOUT  LISTENING  PORT 

Does  the  IUT  send  a  correct  reset  when  it  receives  the  SYN  of  an 
Active  Open  with  Data  for  a  non-existent  port? 

-  Action:  The  LSD  initiates  an  Active  Open  with  Data  to 

a  port  on  the  IUT  without  a  listening 
process . 

-  Verification:  Check  the  TCP  segments  collected  by  the 

REF.  The  IUT  reset  segment  must  have  the 
format:  sequence  number  =  0;  acknowledgment 
number  =  the  sequence  number  of  the  last  byte 
of  data  on  the  REF's  SYN  segment;  and  the  ACK 
and  RESET  flags  are  set.  If  the  IUT  has  not 
passed  the  Active  Open  with  Data  test,  the 
reset  segment  must  have  the  expected  format 
of  Test  63. 

-  Success:  IUT  uses  correct  reset  segment  format. 

-  Failure:  IUT  uses  incorrect  reset  segment  format. 


TEST  70:  RESET  FORMAT  ON  RECEIPT  OF  INVALID  SEGMENT  WITH  ACK  SET 


Does  the  IUT  send  the  correct  reset  format  on  receiving  a  segment 
with  ACK  set  for  a  non-existent  port? 

-  Action:  The  LSD  initiates  an  Active  Open  to  a  port  on 

the  IUT  without  a  listening  process.  The  REF 
omits  the  SYN  from  its  initial  segment  but 
sets  the  acknowledgment  flag  and  puts  a  value 
in  the  acknowledgment  number. 

-  Verification:  Check  the  TCP  segments  collected  by  the 

REF.  The  IUT's  reset  must  have  the  format: 
sequence  number  =  acknowledgment  number  on 
the  REF's  initial  segment;  also  the  RESET 
flag  ls  set.  The  ACK  flag  must  not  be  set. 

-  Success:  The  IUT  uses  correct  reset  segment  format. 

-  Failure:  The  TUT  uses  incorrect  reset  segment  format. 


TEST  71:  RESET  FORMAT  ON  RECEIPT  OF  INVALID  SEGMENT  WITH  SYN  AND 
-  ACK  SET 

Does  the  IUT  send  a  correct  reset  on  receiving  a  SYN  segment  with 
ACK  set  for  a  port  in  LISTEN  state? 

-  Action:  The  PD  docs  a  Passive  Open.  The  LSD  does  an 

Active  Open.  The  REF  places  an 
acknowledgment  on  its  SYN  segment. 

-  Verification:  Determine  that  no  connection  is 

established.  Check  that  an  OPEN  FAILURE  is 
reported  from  the  REF.  If  the  connection 
attempt  correctly  fails,  check  the  TCP 
segments  col  Lected  by  the  REF.  The  IUT  reset 
must  have  the  following  format:  sequence 
number  =  acknowledgment  number  on  the  REF's 
initial  segment,  and  the  PESET  flag  is  set. 

The  ACK  flag  must  not  be  set. 

-  Success:  The  IUT  resets  and  uses  correct  reset  format. 

-  Failure:  The  IUT  establishes  connection  after 

receiving  invalid  SYN  segment,  or  the  IUT 
uses  incorrect  reset  segment  format. 


TEST  72:  NO  RESET  ON  RECEIPT  OF  SEGMENT  WITH  BAD  ACK 


Does  the  IUT  erroneously  perform  a  reset  on  receiving  a  segment 
with  a  bad  acknowledgment  number? 

-  Action:  The  LSD  and  the  RD  establish  a  connection. 

The  LSD  sends  data  to  the  the  RD.  The  REF 
places  an  incorrect  acknowledgment  number  on 
an  outgoing  segment.  The  REF  retransmits  the 
bad  segment  three  times  and  then  corrects  it. 

-  Verification:  Determine  that  the  IUT  does  not  terminate 

the  connection.  If  the  connection  is  not 
terminated,  check  the  TCP  segments  collected 
by  the  REF  to  determine  that  the  IUT  has 
transmitted  empty  acknowledgments.  These 
acknowledgments  must  have  the  format: 
sequence  number  =  IUT's  current  segment 
sequence  number;  acknowledgment  number  =  the 
sequence  number  of  the  REF's  segment  (not 
incremented  to  acknowledge  any  of  the  data  on 
the  bad  segment);  and  the  ACK  flag  must  be 
set . 

-  Success:  The  IUT  sends  empty  acknowledgments  until  it 

receives  the  corrected  segment.  The 
connection  is  not  reset. 

-  Failure:  The  IUT  resets  the  connection  on  receiving 

the  bad  data  segment  or  the  IUT  acknowledges 
data  segments  with  bad  acknowledgment  number. 


Scenario  QUAL 

Scenario  QUAL  tests  the  TCP  implementation  to  determine  how  many 
TCP  connections  it  is  able  to  provide.  The  scenario  tests  up  to 
145  connections. 

TEST  73:  NUMBER  OF  TCP  CONNECTIONS  RESOURCES  CAN  SUPPORT 


Determine  the  maximum  number  of  TCP  connections  provided  bv 
the  IUT. 

The  LSD  performs  12  Passive  Opens.  The  RD  is 
instructed  to  consecutively  open  12  active 


Action: 


connections  to  each  of  these  ports  until  it 
runs  out  of  resources. 

Verification:  Count  every  connection  where  an  OPEN 

SUCCESS  is  the  response  received  on  the  IUT 
Active  Open  Request.  When  the  response  TCP 
ERROR:  INSUFFICIENT  RESOURCES  is  found  or  144 
connections  are  opened,  the  test  is  ended. 

The  total  number  of  connections  the  IUT  can 
support  equals  the  number  of  connections  the 
RD  has  opened  plus  the  connection  for  the 
command  channel. 

Observation:  The  total  number  of  connections  the  IUT  is 

able  to  support  is  noted.  If  the  IUT  is  able 
to  support  more  than  145  connections  (it  does 
not  run  out  of  resources),  this  observation 


